Freaks Macintosh Archive/Freaks Macintosh Archive.bin/Freaks Macintosh Archives/Hacking & Misc/Mac Satellite.sit/Mac Satellite/Season9 Info/details.txt

Text File | 1995-08-28 | 29KB | 557 lines

Some technical details about Videocrypt
---------------------------------------

Markus Kuhn -- 1994-08-02


In this file, I'll collect some of the details known or assumed about
the Videocrypt pay-TV access control system. Consider it as some kind
of frequently asked questions list with answers about the system.


1  Basic principle

Videocrypt encodes the TV image by cutting each line of the image in
two pieces at some cut point and then exchanges these two line
fragments in the broadcasted pictures. E.g. if a line like

   0123456789

passes the encoder, the output might look like

   4567890123

where the digits represent the pixels of the image. There are 256
possible cut points and there are no cut points directly near the image
border (the miniumum distance from the margin is about 12-15% of the
image width) which is the reason why you sometimes still can see
vertical patterns even on an encrypted image. The sound is currently
not encrypted.

Several times per second, a computer at the broadcasting station
generates a 32 byte long message which is broadcasted encoded together
with forward error correction information in the first invisible lines
of the TV signal similar to teletext. About every 2.5 seconds, one of
these 32-byte messages is processed in the encoder by a secret hash
algorithm which transforms the 32-byte message into a 60-bit value.
These 60 bits are then used by a second algorithm in order to determine
the 8-bit cut point coordinates for each line for the next 2.5 seconds.
No details about this second algorithm are known, but think of it just
as some kind of 60-bit pseudo random number generator (PRNG) were the
60-bit output from the secret hash function is used as a start value
(seed).

The decoder receives the 32-byte messages and other data together with
the TV signal, applies some error correction algorithms and passes all
32-byte packets to the smart card in the decoder's card slot. The smart
card implements the same secret hash function and answers with the same
60-bit value as the one which is used in the encoder. By using this
60-bit answer from the card, the decoder hardware can generate with the
same PRNG the same cut point sequence as the encoder and can so
reconstruct the original image by again exchanging the two line
fragments. The secret hash function is a cryptographically strong
system which is designed so that it is extremely difficult to guess the
algorithm of this function by looking at many pairs of 32-byte/60-bit
values.

Apart from being the source for the generation of the 60-bit PRNG seed,
the 32-byte messages from the broadcasting station contain card numbers
so that individual cards can be addressed and they contain commands
like activation, deactivation and pay-per-view account modification. In
addition, the 32-byte packets contain a digital signature (currently 4
bytes) that allows the card to test whether the 32-byte messages really
originate from the encoder and have not been generated by someone
analysing the card. Again, this digital signature like the hash
function has been designed so that it is difficult to find out how to
generate a correct signature by looking at enough examples. This
prevents choosen-text attacks, where someone tries to probe the secret
hash function with very carefully selected 32-byte messages and this
prevents hackers to generate new activation commands for the card.

In early 1993, someone managed to get access to the secret hash
functions of several stations which use Videocrypt (e.g., British Sky
Broadcasting, Adult Channel, JSTV, BOB, Red Hot TV). Most of these
systems used the same hash and signature algorithm and the only
difference between the stations was a 32-byte secret key table. It is
not known, how it was possible to get this information. Either someone
from the company who manufactured the cards (News Datacom Ltd.)
released this information or it was possible for someone to read out
the EEPROM contents of the card processor (very difficult, but
theoretically possible). With this knowledge it was then quite easily
possible for the original hackers to produce 'clone cards'. These are
simple PCBs with a cheap microcontroller (e.g. one of Microchip's PIC
family), which implements only the secret hash function and serial I/O
procedures in its EPROM and answers with the correct 60-bit values to
32-byte messages just as the real cards do. For several channels, clone
cards are still available, but BSkyB distributed new 09 series cards in
spring 1994 and switched on 1994-05-18 to a new secret hash ans
signature function. Consequently, all clone cards stopped to work.

The clone cards didn't implement any interpretation procedures for card
activation, deactivation and pay-per-view functions, so their software
is considerably simpler than the one in the real cards. This resulted
in some tiny differences between the reaction of the clone card
software and the reaction of the original card software on pathological
32-byte messages. These differences were used in counter measures
(commonly referred to as ECMs) against clone cards several times in
1993 and 1994 by BSkyS and News Datacom in order to deactivate clone
cards, but it was quite easy each time to find out these tiny bugs in
the clone card software and correct it.

There are two microprocessors in a typical Videocrypt decoder. An Intel
8052 microcontroler manages the communication between the smart card
and the rest of the system. As the software of this processor is not
read protected, it was also possible to reprogram this chip (by using
the EPROM version 8752BH) so that the hash algorithm is performed
inside the decoder. Then no external card is needed at all for the
channels for which the hash algorithm was implemented in the 8752. The
second processor is a Motorola 6805 variant and its internal ROM
contents can't be read out easily. The Motorola decodes the data that
comes with the TV signal, applies error correction algorithms to this
data, exchanges the 32-byte messages and 8-byte answers with the Intel
processor and controls the PRNG and the on-screen display hardware.

There are also Videocrypt II decoders available. These work almost like
the Videocrypt decoders and the only important difference is a new
software in the Intel and Motorola processor. Videocrypt II decoders
get their data from other invisible TV lines than Videocrypt, and it is
possible to broadcast a signal encrypted in a way that allows both
Videocrypt and Videocrypt II to decode it with different smart cards.

More detailed basic information about Videocrypt has been published in
the European patent EP 0 428 252 A2 ("A system for controlling access
to broadcast transmissions"). You can order a copy for little money
(about 10 DM) from the European Patent Office (Schottenweldgasse 29,
A-1072 Wien, Austria) if you are interested.


2  Security of the Videocrypt system

The system is very secure, because all secret parts that are essential
to a successful decryption are located in the smart card and if the
card's secret hash algorithm/key becomes known, it can easily be
replaced by just sending new cards to the subscribers. This card
exchange can also be used if details about the format of the commands
hidden in the 32-byte sequences sent to the card become known which
allows together with the knowledge of the signature algorithm to
generate new activation messages and to filter out deactivation
messages.

There are however at least two obvious security flaws of the system
which can't be removed by new smart card generations:

  - The dialog between the card and the decoder is the same synchronously
    for all Videocrypt decoders switched to this channel. I.e., the decoder
    doesn't add any card specific or decoder specific information to the
    traffic. This makes it possible to use one card for several decoders.
    E.g. it is possible to record the 32-byte messages broadcasted by
    the station during an evening with a PC, then send these messages to
    someone else with an original card who asks his card for the 60-bit
    answers to all the recorded messages. If this person then sends
    these 60-bit answers back, then you can use this data in order
    to descramble the VCR recorded program of this evening (delayed data
    transfer). However, decoding VHS recorded encrypted signals produces
    minor color distortions and a few VCRs don't preserve the Videocrypt
    data stream in the first invisible lines that accompanies the TV
    signal. It is also possible to distribute the 60-bit answers from
    one card in real-time with cables to many decoders in a house or
    with radio signals to many decoders in a larger region.

  - The simple cut-and-exchange encryption method and the fact that two
    consecutive lines in an image are almost always nearly identical
    makes it possible to try all 256 possible cut points and to select
    the one which causes both lines to fit together best. This method
    has alreday been implemented on fast PC's with framegrabbers which
    load the image into the memory and display it corrected on the computer
    screen (many seconds per frame), on parallel supercomputers which
    allow almost real-time decryption and with special hardware that
    achieves real-time decryption. Howevery, with this decoding method,
    there are severe image quality losses and many additional problems
    which together with the high hardware costs required (much higher
    than a regular subscription) don't make this approach very practical
    for every day usage.

Both these security gaps in the videocrypt systems don't allow
comfortable and easy high quality decryption like using a card, but the
described methods have already been successfully used by a few
technically skilled peoples for watching encrypted program.


3  ISO card protocol

The card and the protocol used to cummunicate with it conform exactly
to the international standard ISO 7816. The options used from this
standard are: T=0 asynchronous halfduplex character transmission
protocol, active low reset and inverse convention. Only a few basic
principles of the ISO protocol will be explained here. For much more
detailed information, please read the ISO standard which you can order
from your national standards body (e.g. DIN, ANSI, AFNOR, BSI, DS,
etc.). There are three parts of the standard: ISO 7816-1 describes
physical characteristics of the card and quality tests a card has to
survive, ISO 7816-2 describes the location and meaning of the contacts
and ISO 7816-3 (most important) describes the electrical
characteristics, the answer-to-reset message and the protocol.

The data format is an asynchronous 9600 bit/s serial format similar to
that used on RS-232 lines with 8 data bits, 1 parity bit and two stop
bits. The parity is even (but if inverse bit meaning convention is
used, a RS-232 interface has to be programmed for odd parity in order
to produce the correct bit). There is also an error detection and
character repetition mechanism in the protocol which is not supported
by RS-232 interfaces: If the receiving device (card or decoder) detects
a parity error, it sends an impulse during the stop bit time. This will
tell the sender to retransmit one byte.

After a reset impulse to the card, the card answers with an
answer-to-reset message with some information about the requirements of
the card. If the first byte is 3fh, then this means that in order to
read the bytes with a RS-232 interface, you'll have to invert and
reverse all bits. A typical answer-to-reset looks e.g. like the
following one:

     3f fa 11 25 05 00 01 b0 02 00 00 4d 59 00 81 80
         |  |  |  |  | | 'historic characters' with|
         |  |  |  |  | | information about chip and|
         |  |  |  |  | | software version, etc.    |
         |  |  |  |  |
         |  |  |  |  +- low nibble: protocol type T=0,
         |  |  |  |     high nibble: end of ISO part
         |  |  |  |
         |  |  |  +- requests 5 additional stop bits
         |  |  |
         |  |  +- encodes programming voltage and max. programming
         |  |     current (here: 5V, 50mA)
         |  |
         |  +- clock freq.: 11h=3.5 MHz, 31h=7 MHz
         |
         +- the 0ah low nibble means: 10 'historic characters' which
            are not defined in the ISO standard are appended to
            the reset answer

The answer-to-reset message has a variable length format. Some bits
specify whether certain bytes are present or not. If the lowest bit in
the high nibble of the second byte is 1, then the above shown third
byte is present and determines the relation between the bit rate and
the clock frequency after the reset answer. E.g., 11h means that 372
clock cycles are one bit duration (default), i.e. with a clock
frequency of 3.5712 Mhz, the bit frequency is 9600 Hz. In the
Videocrypt system, the bit rate is always 9600 bits/s, but a value of
31h (= factor 744) in the third byte requests a doubled clock frequency
(~7MHz) from the decoder. Other values are not supported by the
Videocrypt decoder.

The Videocrypt decoder supports several programming voltages (5 V, 12.5
V, 15 V and 21 V, max. 50 mA current) and different numbers of stop
bits (>= 5) sent to the card. All these parameters can be selected in
the answer-to-reset. Of the 'historic characters' part, the decoder
only verifies that it is at least 7 characters long and that the values
4dh und 59h are at the positions as in the example, otherwise the card
is rejected. No more details about the information in the historic
characters part of a Videocrypt card is currently known. For the
detailed format of the answer-to-reset message, please consult ISO
7816-3.

The T=0 protocol is a half duplex master slave protocol. The decoder
can send commands to the card followed by a data transmission either to
or from the card. The card can do some limited flow control and can
request or deactivate the programming voltage VPP selected in the
answer-to-reset using "procedure bytes". If the decoder initiates a
command, it sends five header bytes to the card, e.g.

     53 78 00 00 08

The first byte (CLA) is the command class code and is always 53h in the
Videocrypt system. The second byte (INS) is the instruction code. Its
lowest bit is always 0 and instruction codes have never a 6 or 9 high
nibble (you'll see below, why). The following 2 bytes (P1 and P2) are a
reference (e.g. an address) completing the instruction code and a
Videocrypt decoder sets them always to 00 00. The final byte (P3) codes
the number of data bytes which are to be transmitted during the
command. P3=0 has a special meaning: In data transfers from the card,
it indicates 256 data bytes, in data transfers from the decoder, it
indicates 0 bytes. The direction of the data transfer is determined by
CLA and INS and must be known in advance by both the card and the
decoder.

After transmission of such a 5-byte header, the decoder waits for a
'procedure byte' from the card.

The following procedure bytes are possible:

  60h             Please wait, I'll send another procedure byte soon,
                  don't timeout.

  INS             Now let's transfer all (remaining) data bytes, I don't
                  need programming voltage.

  INS+1           Now let's transfer all (remaining) data bytes and please
                  activate VPP.

  INS xor ffh     Now let's transfer another single data byte,
                  I don't need programming voltage.

  (INS+1) xor ffh Now let's transfer another single data byte, and please
                  activate VPP.

  6Xh or 9Xh      This byte SW1 indicates an end of the data transfer
                  and requests to deactivate VPP. A second status byte SW2
                  follows from the card. SW1 SW2 = 90 00 indicates a
                  normal termination, other values report e.g. an error.

After each data transfer, the decoder waits for another procedure byte.
E.g., a typical decoder<->card dialog looks like this (command 78h
requests the 60-bit answer as 8 bytes from the card):

     decoder sends header
       53 78 00 00 08
     card sends procedure byte (all at once, no VPP)
       78
     card sends P3 data bytes
       80 52 02 79 f5 39 7c 0e
     card closes with SW1 and SW2
       90 00


4  Videocrypt protocol

The newer Videocrypt smart cards don't require any programming voltage
(the VPP pin isn't even connected). Although, the ISO standard requires
only 2 stop bits after each transfered byte, Videocrypt decoders seem
to require more than 5 stop bits. As PC serial ports don't support more
than 2 stop bits directly, a card emulator software has to wait for
about 0.5-1.5 ms after each byte. Cards can announce in the
answer-to-reset message, how many stop bits they require and Videocrypt
cards also do require more than 2 stop bits.

A videocrypt decoder knows the following 10 commands (all with CLA=53h
and P1=P2=00h):

     INS     length (P3)      direction        purpose
    ---------------------------------------------------------------------
     70h         6            from card        serial number, etc.
     72h        16            to card          message from previous card
     74h        32            to card          message from station
     76h         1            to card          authorize button pressed
     78h         8            from card        60-bit answer
     7ah        25            from card        onscreen message
     7ch        16            from card        message to next card
     7eh        64            from card        ??? \
     80h         1            to card          ???  > perhaps Fiat-Shamir
     82h        64            from card        ??? /  authentication?

The following things are known about the data bytes of these commands:

70h:

In BSkyB cards, the 70h data contains the card issue number (e.g. 07 or
09) in the low nibble of the first byte. The high nibble of the first
byte seems to be always 2. The next 4 bytes form an 32-bit bigendian
integer value which corresponds to the decimal card number without the
final digit of the card number (which is perhaps a check digit,
algorithm unknown). The meaning of the final byte is unknown.

72h and 7ch:

Several times per second, the decoder requests with 7ch 16 bytes from
the card. If a card is removed and a new card is inserted in the
decoder without switching off the power of the decoder, then shortly
after the card reset, the decoder sends the latest 7ch data bytes from
the previous card in a 72h message to the new card. In this way, 16
bytes information (e.g. the status of a pay-per-view account or a list
of activated channels?) can be transfered from one card to the next.

74h and 78h:

The 74h command transfers the 32-byte messages from the broadcasting
station to the card. If the third bit (value 8) in the first byte is
set, then the decoder will ask with a 78h command for the 60-bit
answer. This happens about every 5th 74h packet every 2.5 seconds. The
high nibble of the final byte in the 78h data is ignored by the decoder
(only 60 bits are needed). The high nibble of the first 74h byte seems
to have the value eh or fh in normal encrypted operation and ch or dh
in the 'soft scrambled' mode where the decoder can descramble the image
even without any card.

The following information is valid for the 07 and 09 BSkyB card and need not
necessarily be true for future smart cards, because these data bytes
don't seem to be interpreted in the decoder and so their meaning can be
exchanged. A typical BSkyB 74h packet for the 09 series card looks like
this:

  e843 0a888261 0c 29e403f6 20202020202020202020202020202020 fb54ac02 51

The second byte indicates the current date and counts the months since
January 1989. In the 07 card, this month code selects one of several
32-byte secret key tables that are used by the hash function. When the
switch from the 07 hash algorithm to the new 09 algorithm happened on
1994-05-18, this value jumped from 40h (1994-05) to 43h (1994-08) which
might indicate that the activation of the 09 algorithm was originally
planned for August. In the 07 card, this value was only interpreted to
find an offset into a table with various 32-byte secret keys.

The third byte seems to be a random number. This byte together with the
month code is used to generate with a quite simple algorithm four XOR
bytes which are necessary to decode the command byte and the card
number prefix (described below). If you XOR these four bytes with bytes
8 to 11 and if you the XOR only the first of the four bytes with byte
4, then you have decrypted the card number and the command code.

The fourth byte is an encrypted command code. Some decrypted known
values are:

    0x00    Deactivate whole card (message: 'PLEASE CALL 0506 484777')
    0x01    Deactivate Sky Movies (message: 'THIS CHANNEL IS BLOCKED')
    0x02    Deactivate Movie Channel
    0x03    Deactivate Sky Movies Gold
    0x06    Deactivate Sky Sports
    0x08    Deactivate TV Asia
    0x0c    Deactivate Multichannels
    0x20    Activate whole card (remove 'PLEASE CALL 0506 484 777')
    0x21    Activate Sky Movies (remove 'THIS CHANNEL IS BLOCKED')
    0x22    Activate Movie Channel
    ...
    0x2c    Activate Multichannels
    0x40    Pay-per-view account management command
    0x80    \
    0x81     \   perhaps 09 card ECM
    0xf0     /   commands
    0xf1    /

Packets with incorrect command bytes and correct signatures can
irreversibly kill a card (it doesn't even answer the reset).

The fifth and sixth byte seem to be parameters for pay-per-view account
management (program number and number of tokens) and don't seem to have
a meaning for enabling and disabling commands.

The lower 7 bits of the seventh byte contain a channel ID.

A card number is represented by a 5 byte card address consisting of a 4
byte prefix and a 1 byte suffix. The five bytes for a card are
identical to the first 5 bytes of the 70h answer, only the high nibble
of the first address byte seems to have a different purpose (unknown).
Up to 16 cards with the same card address prefix can be addressed with
one single 32-byte 74h message. The bytes 8-11 might contain the common
prefix to the addressed cards and the bytes 12-27 the various suffixes.
If there are less than 16 different cards to be addressed, then the
same suffix byte is repeated several times in order to fill the space.
The 4-byte prefix is encrypted like the command byte by XORing it with
the four bytes generated using the bytes 2 and 3.

The 4 bytes 28-31 contain the digital signature which is simply an
intermediate result of the iterations of the hash algorithm. If the
checksum, the digital signature, or some of the values in the first 7
bytes of a 74h command aren't correct, then the 78h answer will only
contain 8 00 bytes or in some cases 01 00 00 00 00 00 00 00. The final
byte 32 is a simple checksum that makes the sum of all 32 bytes a
multiple of 256.

The 07 card (and also cards used by Sky New Zealand) have an
interesting security hole: The card sends to the decoder as many data
bytes as specified in P3. By sending a higher length value in the
command header to the card, one can get up to 256 data bytes back which
seem to be values from the card's RAM that allow some insight into the
internal data structures of the card software.

76h:

If the authorize button on the decoder is pressed for a few seconds,
then the decoder will send a single 76h message with a 00 data byte to
the card.

7ah:

This command requests from the card an ASCII text which is then
displayed on the TV screen. The display field is 12 characters wide,
one or two lines high and no lowercase letters are supported. The lower
5 bits in the first byte indicate, how long the text is which is to be
displayed: 0 for no display, 12 for a single line and 24 for 2 lines.
The highest 3 bits of the first byte seem to be some kind of display
priority. The number there (0-3) must be high enough if standard
decoder messages have to be suppressed. The remaining 24 bytes contain
the ASCII test.

The meaning of the other commands is unknown, some of them are never
used currently. Perhaps these commands are used for the Fiat-Shamir
identification exchange described in the patent. Some cards understand
also additional instruction codes which can't be issued by a normal
decoder. E.g. a BSkyB 09 card understands also 12h, 86h, 88h, 8ah and
8ch. These commands are perhaps used in order to test or configurate
the card at the factory, etc.

Please contact me if you find out anything new. My e-mail address is
[e-mail].


5  VCL File Format

The Videocrypt Card Logfile format (VCL) is used by some peoples for
performing the delayed data transfer procedure described in section 2.
Person A with a valid card can record the dialog between the decoder
and the card for a certain program P and transmit this information as a
VCL file to person B who has no card and has recorded with a VCR only
the encrypted signal of program P. Person B now connects the Videocrypt
decoder between the VCR and the TV set and connects the card slot of
the decoder to a PC. Using the information in the VCL file, B's
computer can now also decrypt program P. This is of course only
possible for the few hours which are covered by the information in the
VCL file.

Not all of the information exchanged between the card and the decoder
is necessary for descrambling the TV signal. The VCL format uses this
fact in order to save a lot of storage space. Only 12 bytes of high
entropy (that means: almost uncompressable) are stored every 2.5
seconds. So a VCL file of a 1 hour program is only about 17 kbytes
large. In addition, VCL files don't contain any information about the
card owner (especially not the card serial number), which appears in
normal full log files. (The only potential security hole is the
remaining nibble in the 78h data, consequently it should be cleared in
order to avoid card specific information to leak into the VCL file.)

VCL files have a very simple binary format consisting of a 128 byte
header and arbitrarily many 12 byte records. At the end, VCL files may
be padded with zero bytes to a multiple of the operating system's disk
sector size, so that no RAM contents can leak in there out of an
unsecure system like MS-DOS. Don't forget to use a binary mode if you
transfer VCL files or their contents will be rendered unusable.

The 128 byte header has the following format:

      byte number       purpose

    0 -  3        ASCII String 'VCL1' which identifies the file
                        type and version of the format.
        4 -  7          The number of 12-byte records stored in this
                        file encoded as a bigendian (most significant
                        byte first) 32-bit unsigned integer value.
        8 - 23          Date and time when the recording started.
                        Format: yyyymmddThhmmssZ, where yyyymmdd are
                        year, month and day (e.g. '19940618'), hhmmss
                        are hour, minute and second (e.g. '235959'),
                        T ist just the ASCII letter T, and Z is
                        the ASCII letter Z if the time is UTC or
                        a zero byte, if the time is local time. The
                        digits are ASCII characters.
       24 - 55          Name of the satellite or cable system from
                        which the recording was done. This is a zero
                        terminated ASCII string with only characters
                        between 20h and 7eh. As many zero bytes are
                        appended as necessary for filling up the 32
                        bytes. The same format is also used for the next
                        two text fields. Example: 'Astra'.
       56 - 63          Name/number of the transponder from which
                        the recording was done. Example: '08' for
                        Sky One on Astra.
       64 -127          Description of what has been recorded.
                        Example: 'Star Trek: TNG, episode 123'

After the first 128 bytes follow as many 12 byte records as announced
in bytes 4-7. Each record represents a 74h/78h Videocrypt protocol pair
and constists of two fields: The first 4 bytes are the final 4 bytes of
the 74h data part, the remaining 8 bytes are the data part of the
corresponding 78h command. Four bytes of each 74h packet are enough to
allow a card emulator to quickly and reliably synchronize with the
queries of the decoder. The final four bytes of the 74h commands have
been selected because of their high entropy (signature and checksum).